FIG. 1 is a diagram that illustrates an exemplary protocol stack 100 supporting a service layer 102. From a protocol stack perspective, service layers 102 are typically layered on top of application protocol layer 104 and provide value added services to client applications. Hence, service layers 102 are often categorized as ‘middleware’ services.
An M2M/IoT service layer is an example of one type of service layer specifically targeted towards M2M/IoT type devices and applications. FIG. 2 is a diagram that illustrates an exemplary deployment scenario of a M2M/IoT service layer instances within a network. In this example, a service layer instance 202 is a realization of a service layer and a number of service layer instances are deployed on various network nodes (gateways and servers). The service layer instances provide value-added services to network applications, device applications as well as to the network nodes themselves.
Recently, several industry standards bodies (e.g., oneM2M) have been developing M2M/IoT service layers to address the challenges associated with integration of M2M/IoT types of devices and applications into deployments such as the Internet/Web, cellular, enterprise, and home network. A M2M service layer can provide applications and devices access to a collection of M2M centric capabilities supported by the service layer. A few examples of such capabilities include security, charging, data management, device management, discovery, provisioning, and connectivity management. These capabilities are made available to applications via APIs which make use of message formats, resource structures and resource representations defined by the M2M service layer.
The purpose and goal of oneM2M is to develop technical specifications which address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect a wide variety of devices in the field with M2M application servers worldwide.
FIG. 3 is a diagram that shows a oneM2M common services layer 302 that supports a set of Common Service Functions (CSFs) (i.e. service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE) 304 which can be hosted on different types of network nodes, e.g. Infrastructure Node (IN), Middle Node (MN), and Application-Specific Node (ASN) CSE are termed by IN-CSE, MN-CSE and ASN-CSE).
FIG. 4 is a diagram that shows a oneM2M service layer compliant to the Resource-Oriented Architecture (RoA) design principles. Within the oneM2M RoA RESTful architecture (as shown in FIG. 4), CSFs are represented as a set of “resources”. A resource is a uniquely addressable element in the architecture having a representation that can be manipulated via RESTful methods such as Create, Retrieve, Update, and Delete. These resources are made addressable using a Universal Resource Identifiers (URIs). A resource may contain child resource(s) and attribute(s). A child resource is a resource that has a containment relationship with a parent resource. The parent resource representation contains references to its child resources(s). The lifetime of a child-resource is limited by the parent's resource lifetime. Each resource supports a set of “attributes” that store information of the resource.
FIG. 5 shows an M2M Service Component Architecture for a legacy deployment that is not RESTful based. This M2M Service Component Architecture is primarily suitable for the infrastructure domain where the CSE 502 is viewed as a set of service components. Within the service layer, it contains various M2M services and multiple services can be grouped into service components. In addition to existing reference points, it introduced the inter-service reference point Msc 504. Communication between M2M Service Components (passing over the Msc reference point 504) utilizes a web service approach, which is the most popular technology for building Service-Oriented Architecture (SoA)-based software systems.
It is known that many M2M/IoT devices have some combination of limited battery power, small memory footprint and low throughput links. Accordingly, many of these devices are “sleepy” and occasionally go into a sleep mode for energy saving. This is a major issue leading to node unavailability considered in most of the previous works.
Wireless sensor network (WSN) is a typical M2M area network that is comprised of a number of low-power devices with sensing and computing capability. In many sensor network systems, the power supply for the network nodes is usually a depletable power source, such as batteries. To increase the lifespan of sensor networks, one power management scheme is to require each network node to wake up periodically to listen to the radio channel. For example, S-MAC is a famous Medium Access Control (MAC) protocol designed for wireless sensor networks. With S-MAC, each node goes to sleep for some time, and then wakes up and listens to see if any other node wants to talk to it. During sleep, the node turns off its radio, and sets a timer to awake it later. The duration of time for listening and sleeping can be selected according to different application scenarios and nodes exchange their schedules by broadcasting to all its immediate neighbors for synchronization. During the awake state, if multiple neighbors want to talk to a node, they need to contend for the medium using Carrier Sense Multiple Access scheme.
Another approach of power management scheme is to use a low-power stand-by hardware component to watch the environment when the node enters sleep mode. For example, a node can use a standby radio-transceiver subsystem to listen to the radio channel when the node sleeps. When the stand-by radio transceiver receives radio signals, it wakes the node up. Otherwise, the node keeps sleeping.
Shortcomings and problems with existing Internet protocols with regards to M2M/IoT use cases (e.g. connecting smart objects to the Internet) have been identified. For example, a major shortcoming of current Internet protocols is that they lack support for sleepy nodes. In other words, it is often assumed that network nodes always remain fully powered, which unfortunately is not the case for many M2M/IoT type devices (that are resource constrained in nature, battery-powered, and sleep a large majority of the time). Accordingly, recently much focus and attention have been given to enhance the architecture and protocols of the Internet to support M2M/IoT networks. For example, prior systems describe a mechanism of sleep mode control, in which the router can control IPv6 sleepy nodes and deliver the packets from/to exterior networks, or described the enhancement of 6LoWPAN Neighbor Discovery (ND) protocol with sleepy node support.
IETF Constrained Application Protocol (CoAP) is a recently developed application protocol specifically for constrained nodes/networks such as wireless sensor networks deployed for smart homes. It has attracted increasing attention and is a promising messaging protocol for IoT systems. In particular, some work has been done to enhance the CoAP protocol for supporting sleepy nodes.
Beyond the CoAP protocol enhancement as mentioned above, other efforts have also been made for supporting sleepy nodes within the IETF Constrained RESTful Environments (CoRE) working group. For example, one of the ideas is to adopt a Resource Directory (RD) mechanism where sleepy nodes can register/update their list of resources (as well as their sleeping-related status) on a central (non-sleepy) RD server. This allows clients to discover the list of resources from the RD for a sleepy node and determine whether a targeted resource is located on a sleepy node, whether a sleepy node is currently in sleep mode, or when a sleepy node will be in awake state again. Another example is related to Mirror Server (MS), which is a web server that allows a sleepy node to create resources in the MS resource tree. In particular, for energy efficiency, a sleep node is a client-only endpoint and hence is not able to serve content by itself. In other words, a MS acts as a mailbox between the sleepy node and the client.
FIG. 6 is a diagram that shows a resource called <schedule> 602 from the oneM2M functional architecture specification. The <schedule> resource 602 represents the scheduling information in the context of its parent resource. When the <schedule> 602 is a child of a <node> resource, it can represent the sleeping schedule information stored in the <scheduleElement> resource 604 so that the service layer can be aware of the node sleeping.
With the foregoing as background information, the present application discloses a new method and system for enabling a node availability estimation service.